By Simon Bisson , Columnist, InfoWorld |

Cloud-native development isn’t as easy as it could be. Platforms such as Kubernetes simplify the process of running a scalable set of services, but you still need to create the application you’re running in the cloud. It’s not a matter of putting your code in a container and writing some configuration YAML; you need much more to have a build that can be deployed anywhere, anytime.

Five years ago, Microsoft acquired the Deis Labs team with the intent of letting them continue to build open source Kubernetes tools. It’s been one of the more successful acquisitions. The team has delivered major upgrades to the Helm Kubernetes packaging tools and the Brigade event-driven workflow system, as well as pioneering WebAssembly in Kubernetes with Krustlets and using Linux device drivers to expose edge hardware to Kubernetes in Akri.

The first post-acquisition release was Draft, a set of command-line tools intended to help you quickly build prototype containerized applications, delivering the scaffolding to develop code on your own PC before pushing it to a Kubernetes instance. It was an interesting experiment but sadly didn’t get the community uptake necessary to take it much further than the initial release. If you go to the list of Deis projects, it’s marked as archived, with no work planned. Even so, it clearly left its mark on those who used it, with Deis regularly asked if they’d take Draft further.

Microsoft certainly noticed the continuing interest in Draft as a tool, as Build 2022 saw the Azure team launch an updated version, Draft 2, for use with Azure’s own managed Azure Kubernetes Service (AKS).

Like the original, Draft 2 is a command-line tool to quickly build a Kubernetes application. Unlike the original, it’s intended to take existing code and package it for use in AKS, building the container and manifest files to run your application in Kubernetes along with the scripts and workflows needed to deploy it from GitHub to AKS.

There are a lot of similarities between the two versions of Draft, but the biggest change is the shift from a local development tool to one based around the Azure CLI and working directly with the cloud. It’s a model that fits with how Microsoft has been evolving its AKS environment, offering it for on-premises systems via Azure Stack HCI or using Azure Arc on your own servers. With Visual Studio Code offering remote development tools for Azure, including the Azure CLI, and with GitHub CodeSpaces being a way to deliver a complete cloud-native developer experience to your desktop, the world has changed significantly since the original Draft was released.

The Draft 2 tool is focused on Azure, GitHub, and AKS, but it remains an open source project so there’s the option of creating your own fork for your chosen Kubernetes environment, whether it’s self-hosted or running on AWS or GCP. Like most Kubernetes tools, it’s written in Go, with workflows in YAML. To build your own Draft 2 install, clone its GitHub repository. With Go 1.118 or better installed, use the familiar make to build the Draft binary before adding it to your system path.

The initial Draft 2 release is part of the aks-preview extension to the Azure CLI. You can run the Azure CLI locally or in Azure as part of the Cloud Shell development and management environment. This means it runs on top of Microsoft’s internal Debian-based BL-Delridge, which hosts Azure’s Cloud Shell. This should ensure that Draft 2 will run on any Debian-derived Linux with minimal work, as the only difference between CBL-Delridge and Debian is that Microsoft compiles all the packages itself for security reasons.

There aren’t many prerequisites for using Draft 2. All you need is Azure CLI, an AKS cluster, and an Azure Container Registry instance. Once you’ve installed the aks-preview extension, it gives you the tools you need and somewhere to store and run your application containers. Installing the extension is simple enough by using the following command: az extension add —name aks-preview. Use az extension update —name aks-preview to make sure you have the latest version.

With Azure CLI configured to use Draft 2, you can take an existing application and turn it into a Kubernetes application. From your application directory, call the Azure CLI and Draft: az aks draft create. If you prefer, you can use Draft’s destination flag to target a specific directory. This generates the files needed to build your application, including the necessary Dockerfile.

Where Draft 2 differs from the original version is its integration with key parts of the Azure and GitHub deployment workflow. You’re now able to quickly build a GitHub Action that automates the process of pushing code artifacts from GitHub to AKS. Draft now has a draft setup-gh command that registers with your GitHub account using OpenID Connect and links it to your Azure Container Registry. Once that link is in place, you’re ready to build your deployment workflow, starting from your local clone of your application. Use the az aks draft generate-workflow to build the action.

Once an action has been built, you’ll need git to push it back to your application repository in GitHub, ready for use via the Actions tools. You can then edit code locally using tools like Visual Studio Code, saving back to an appropriate branch using the Code GitHub extension via pull requests. If you’ve automated your action, a pull request will trigger a build and deliver your application to AKS, ready for testing.

Microsoft has provided a shortcut to use Draft with a fresh application in a new cloned repository. By using the draft up command, you will authorize access and build an action in a single line. If you need to modify an action, use generate-workflow again. Finally, you can use the draft update command to enable AKS web application routing. A Nginx-based ingress controller adds internet access to your application and supports the Open Service Mesh tools in AKS to help secure your code.

It’s good to see Microsoft bringing Draft back. Tools such as this are an essential step for any cloud-native migration, taking code and automating the process of building the scripts and manifests needed to run it on Kubernetes. It’s also interesting to see another Azure tool taking a dependency on a GitHub feature, an approach that’s likely to become more prevalent in future as the two organizations increasingly work together on projects.

Author of InfoWorld's Enterprise Microsoft blog, Simon Bisson has worked in academic and telecoms research, been the CTO of a startup, run the technical side of UK Online, and done consultancy and technology strategy.

Copyright © 2022 IDG Communications, Inc.

Copyright © 2022 IDG Communications, Inc.